D. 17/02/2005 n. 4

a) SubjectDirectoryAttributes (OID: 2.5.29.9). Essa non contiene alcuno dei campi indicati ai commi 3 e 4. L'attributo dateOfBirth (OID: 1.3.6.1.5.5.7.9.1), se presente, è codificato nel formato GeneralizedTime. L'estensione non è marcata critica;

b) authorityInfoAccess (OID: 1.3.6.1.5.5.7.1.1).Nel caso in cui il certificatore metta a disposizione, conformemente all'art. 10, un sistema OCSP per la verifica della validità di un certificato, l'estensione Authority Info- Access contiene un campo accessDescription con la descrizione delle modalità di accesso al servizio OCSP, e contiene i seguenti attributi:

1) accessMethod , che contiene l'identificativo id-ad-ocsp (OID:.3.6.1.5.5.7.48.1); 2) accessLocation, che contiene l'URI che punta all'OCSP Responder del certificatore, utilizzabile per effettuare la verifica del certificato stesso. L'URI configura un percorso assoluto per l'accesso al- l'OCSP Responder. Nel caso in cui siano specificati più campi access Description contenenti l'identificativo id-ad-ocsp nell'attributo accessMethod, tali indicazioni configurano diversi percorsi alternativi per l'interrogazione, tramite OCSP, dello stato del certificato.L'estensione non è marcata critica;

c) salvo quanto disposto all'art. 4, comma 5, lettera f), gli eventuali ulteriori limiti d'uso di cui all'art. 43 delle regole tecniche sono inseriti nell'attributo explicitText del campo userNotice dell'estensione certificatePolicies;

d) ulteriori estensioni possono essere inserite nel certificato purchè conformi agli standard citati nella presente deliberazione e non marcate critiche. Titolo III PROFILO DEI CERTIFICATI DI CERTIFICAZIONE E MARCATURA TEMPORALE

Art. 5. - Profilo dei certificati di certificazione e marcatura temporale

1. Se non diversamente previsto, il profilo dei certificati è conforme alla specifica RFC 3280.

Art. 6. - Uso delle estensioni nei certificati di certificazione

1. I certificati di certificazione contengono le seguenti estensioni:

a) keyUsage (OID 2.5.29.15), contiene i valori keyCertSign e cRLSign (bit 5 e 6 impostati a 1). L'estensione è marcata critica;

b) basicConstraints (OID 2.5.29.19), contiene il valore CA=true. L'estensione è marcata critica;

c) certificatePolicies (OID 2.5.29.32), contiene uno o più identificativi delle policyIdentifier e le relative URL del CPS. Può contenere l'OID generico previsto dall'RFC 3280 (2.5.29.32.0).L'estensione non è marcata critica;

d) CRLDistributionPoints (OID 2.5.29.31), contiene uno o più URL di accesso a CRL/CSL. L'URL configura un percorso assoluto per l'accesso alla CRL. L'estensione non è marcata critica;

e) subjectKeyIdentifier (OID 2.5.29.14), contiene il valore keyIdentifier. L'estensione non è marcata critica.

2. Ulteriori estensioni possono essere inserite nel certificato purchè conformi agli standard citati nella presente deliberazione e non marcate «critiche».

Art. 7. - Uso delle estensioni nei certificati di marcatura temporale

1. I certificati di marcatura temporale contengono le seguenti estensioni:

a) keyUsage (OID 2.5.29.15), contiene il valore digitalSignature (bit 0 impostato a 1). L'estensione è marcata critica:

b) extendedKeyUsage (OID 2.5.29.37), contiene il valore keyPurposeId= timeStamping. L'estensione è marcata critica;

c) certificatePolicies OID 2.5.29.32), contiene uno o più identificativi delle policyIdentifier e le relative URL del CPS. L'estensione non è marcata critica;

d) authorityKeyIdentifier (OID 2.5.29.35), contiene almeno un keyIdentifier. L'estensione non è marcata critica;

e) subjectKeyIdentifier (OID 2.5.29.14), contiene almeno un keyIdentifier. L'estensione non è marcata critica.

2. Ulteriori estensioni possono essere inserite nel certificato purchè conformemente agli standard citati nella presente deliberazione e non marcate «critiche». Titolo IV REGOLE PER LA VALIDAZIONE TEMPORALE

Art. 8. - Regole per i servizi di validazione temporale

1. L'accesso al servizio di validazione temporale fornito dai certificatori avviene tramite il protocollo e il formato definiti nella specifica ETSI TS 101 861 V.1.2.1, recante «Profilo di validazione temporale» e nella specifica RFC 3161 e successive modificazioni. Le marche temporali inviate in risposta al richiedente seguono i medesimi standard.

2. I certificatori rendono disponibile o indicano un sistema che permetta l'apertura, l'analisi e la visualizzazione di marche temporali di cui al comma

1. Detto sistema gestisce correttamente le strutture TimeStampToken e TimeStampResp almeno nel formato detached, con verifica della firma del sistema di validazione temporale e della corretta associazione, effettuata tramite la funzione di hash, con il documento per il quale è stata generata la marca temporale stessa.

3. L'estensione associata alla struttura TimeStampToken e TimeStampResp non deve influire sul corretto funzionamento del sistema di cui al comma 2.

4. I TimeStampToken devono includere un identificativo univoco della policy di sicurezza in base alla quale il token stesso è stato generato. Detto identificativo, se non definito a livello nazionale od europeo, è definito e reso pubblico dal certificatore. Titolo V INFORMAZIONI SULLA REVOCA E SOSPENSIONE DEI CERTIFICATI

Art. 9. - Verifica dei certificati – CRL

1. Le informazioni sulla revoca e sospensione dei certificati, pubblicate dai certificatori e disponibili pubblicamente tramite liste di revoca e sospensione, hanno un formato conforme alla specifica RFC 3280, capitolo 5, esclusi i paragrafi 5.2.4 e 5.2.6.

2. Le liste di certificati revocati e sospesi sono accessibili al pubblico tramite protocollo HTTP o LDAP.

Art. 10. - Verifica in tempo reale dei certificati – OCSP

1. Fermo restando quanto prescritto dall'art. 9, i certificatori hanno la facoltà di rendere disponibili le informazioni sulla revoca e sospensione dei certificati, anche attraverso servizi OCSP. In tal caso, detti servizi devono essere conformi alle specifica RFC 2560 e successive modificazioni.

Art. 11. - Coerenza delle informazioni sulla revoca e sospensione dei certificati

1. Se un certificatore mette a disposizione diversi servizi per l'accesso alle informazioni sulla revoca o la sospensione dei certificati, o diversi URL di accesso allo stesso servizio, le informazioni ottenute accedendo con le diverse modalità devono essere coerenti se ciò è compatibile con la tecnologia utilizzata. Titolo VI FORMATI DI FIRMA

Art. 12. - Busta crittografica di firma

1. La busta crittografica destinata a contenere l'oggetto sottoscritto è conforme, salvo i casi previsti dai commi 8 e 9, alla specifica RFC 2315 (PKCS7 ver. 1.5).

2. La busta crittografica di cui al comma 1 è di tipo signedData (OID: 1.2.840.113549.1.7.2).

3. Per la codifica della busta crittografica possono essere utilizzati i formati ASN.1-DER (ISO 8824, 8825) o BASE64 (RFC 1421).

4. Il documento da firmare è imbustato nel formato originale, senza aggiunte in testa o in coda al formato stesso.

5. Il nome del file firmato, ossia della busta, assume l'ulteriore estensione «p7m».

6. Le buste crittografiche di cui al comma 5 possono contenere a loro volta buste crittografiche. In questo caso è applicata una ulteriore estensione «p7m».

7. L'eventuale presenza di attributi autenticati nella busta crittografica non è considerata critica. La gestione degli stessi non deve rappresentare un vincolo per le applicazioni di verifica di cui all'art. 14.

8. Il CNIPA può stabilire, con apposito provvedimento, ulteriori formati standard di busta crittografica, riconosciuti a livello nazionale o internazionale, conformi a specifiche pubbliche (Publicly Available Specification-PAS).

9. Il CNIPA può sottoscrivere specifici protocolli d'intesa al fine di rendere disponibili ulteriori formati di firma. Detti protocolli d'intesa devono contenere l'impegno del sottoscrittore ad assicurare:

a) la disponibilità delle specifiche necessarie per lo sviluppo di prodotti di verifica o di generazione e eventuali librerie software necessarie per lo sviluppo di prodotti di verifica di firme digitali conformi al formato oggetto del protocollo d'intesa;

b) l'assenza di qualunque onere finanziario a carico di chi sviluppa, distribuisce o utilizza i prodotti menzionati al comma precedente;

c) la disponibilità di ogni modifica inerente a quanto indicato alla lettera a) con un anticipo di almeno 90 giorni rispetto alla data del rilascio di nuove versioni del prodotto che implementa il formato di busta crittografica oggetto del protocollo d'intesa;

d) la disponibilità, a titolo gratuito per uso personale, di un prodotto per verificare firme digitali del formato oggetto del protocollo d'intesa e visualizzare il documento informatico oggetto della sottoscrizione;

e) la capacità di utilizzare le informazioni contenute nell'elenco pubblico dei certificatori di cui all'art. 41 delle regole tecniche e nelle liste di revoca di cui all'art. 29 del citato provvedimento nel prodotto di verifica di cui al comma precedente.

10. Fermo restando il rispetto delle condizioni previste al comma 9, il CNIPA, consultando preventivamente le autorità di settore e le associazioni di categoria maggiormente rappresentative, valuta le richieste di sottoscrizione dei protocolli d'intesa previsti dal comma sopra citato avendo riguardo:

a) alla rilevanza delle esigenze che essi consentono di soddisfare;

b) alla possibilità di assicurare un idoneo supporto e un'adeguata diffusione sul mercato nazionale ed internazionale dei prodotti che realizzano la struttura informatica del documento sottoscritto, tali da essere riconosciuti ed accettati quali standard di riferimento;

c) alla necessità di evitare effetti negativi sulla interoperabilità.

11. Le pubbliche amministrazioni possono accettare documenti informatici sottoscritti con i formati di firma di cui ai commi 8 e 9 e, nel caso ritengano opportuno accettare uno o più di detti formati, dovranno farne apposita menzione nei procedimenti amministrativi cui si applicano e comunicarlo al CNIPA. Le pubbliche amministrazioni garantiscono la gestione del formato di cui al comma 1.

12. Il soggetto che sottoscrive il protocollo d'intesa di cui al comma 9 indica al CNIPA gli indirizzi internet dove è possibile ottenere, gratuitamente e liberamente, quanto indicato alle lettere a) e d) del medesimo comma 9.

13. Il CNIPA rende disponibili sul proprio sito internet: l'elenco dei formati oggetto di protocolli d'intesa, gli indirizzi internet di cui al comma 12 e gli eventuali formati di busta crittografica di cui al comma 8.

14. In caso di inadempienza da parte del sottoscrittore del protocollo d'intesa di quanto previsto ai commi 9 e 12, il CNIPA informa tempestivamente il soggetto interessato e, nel caso lo stesso non ottemperi rapidamente alla piena osservanza di quanto previsto, revoca il protocollo d'intesa dandone pubblicità nell'elenco di cui al comma 13 ed informandone tempestivamente le pubbliche amministrazioni di cui al comma 11.

Art. 13. - Regole per l'apposizione di firme multiple

1. Una stessa busta crittografica può contenere più firme digitali. Queste ultime sono identificate in:

a) «Firme parallele», in tal caso il sottoscrittore, utilizzando la propria chiave privata, firma solo i dati contenuti nella busta stessa (OID: 1.2.840.113549.1.7.1);

b) «Controfirme», in tal caso il sottoscrittore, utilizzando la propria chiave privata, firma una precedente firma (OID: 1.2.840.113549.1.9.6) apposta da altro sottoscrittore.

2. Il formato delle firme multiple definite nel presente articolo è conforme alla specifica RFC 2315.

3. L'apposizione di firme multiple di cui al presente articolo non comporta l'applicazione di ulteriori estensioni al file firmato, oltre alla prima. Titolo VII APPLICAZIONI DI VERIFICA DELLA FIRMA

Art. 14. - Requisiti delle applicazioni di verifica

1. Le applicazioni di verifica della firma digitale indicate o distribuite dai certificatori accreditati, ai sensi dell'art. 10 delle regole tecniche, oltre a gestire correttamente i certificati elettronici il cui formato è stabilito nella presente deliberazione, riconoscono i seguenti elementi dei certificati qualificati: